home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9303 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: news.gate.net!not-for-mail
  2. From: dhaire@gate.net (doug haire)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
  5. Date: 27 Mar 1996 04:54:31 -0500
  6. Organization: CyberGate, Inc.
  7. Message-ID: <4jb38n$st4@navajo.gate.net>
  8. References: <4j2fv1$8kf@nnrp1.news.primenet.com> <4j2iun$a3t@newsbf02.news.aol.com> <4j3r1f$1tc4@seminole.gate.net> <4j7ppn$l33@sam.inforamp.net>
  9. NNTP-Posting-Host: navajo.gate.net
  10. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  11.  
  12. Geoffrey Welsh (crs0794@inforamp.net) wrote:
  13. : In article <4j3r1f$1tc4@seminole.gate.net>,
  14. :    dhaire@gate.net (doug haire) wrote:
  15. : >[...] Second, I'd like to point out that comm overruns are a 
  16. : >fault that lies with the operating system software of the CPU. I recently 
  17. : >tested this on a comparison with a large file and two different platforms 
  18. : >(MS-DOS and Linux) on the same CPU. The sender was a  486dx4/100 CPU running 
  19. : >MS-DOS and using a USR Courier V.34 v.everything. The receiver was a 
  20. : >486sx33 with another Courier (same model) running linux and MS-DOS 
  21. : >(separate partitions, dual boot). Modems were connected via an 8 ft 
  22. : >telephone cable and synched at 33,600 bps with V.42 LAPM and V.42bis 
  23. : >compression.
  24. : >
  25. : >The linux platform received the file with no errors, no comm overruns, no 
  26. : >garbled subpackets, no problems.
  27. : >
  28. : >The MS-DOS platform received constant errors such as comm overruns and 
  29. : >garbled subpackets.
  30. : >
  31. : >I also ran the tests using *no* modems (null modem cable connection at 
  32. : >115200 connection rate). The MS-DOS to MS-DOS connection was completely 
  33. : >unusable with way too many errors at the receiver. The MS-DOS to linux 
  34. : >connection was stable and never showed an error.
  35. : 
  36. : This is exactly correct... and I blame it on the crap that passes for MS-DOS 
  37. : device drivers and the foolish ways in which we 'improve' performance, such as 
  38. : blocking interrupts during multi-sector IDE transfers.  However, virtual 8086 
  39. : mode is also a terrible place to run anything timing sensitive, including your 
  40. : OS (DOS).
  41.  
  42. The only platform performing any multi-tasking was the linux one. Th eDOS 
  43. platforms were both just running plain ol' DOS, no Windows, no DesqView 
  44. or any other add-on.
  45.  
  46. : >When the common computer software platform is capable of handling 115200 
  47. : >properly perhaps we can then consider the 230k UART speed.
  48. : 
  49. : Hmm, I'm typing this message on a 386DX-40 running Windows 3.1 and Trumpet.  
  50. : The 28.8 modem is talking to me at 115200 bps and, thanks to a 16550A UART, 
  51. : Trumpet never complains about overruns.  The speed limit on this machine is my 
  52. : ISA VGA card, but I could probably push the limit further for things like ftp 
  53. : if I thought that there was any point.
  54.  
  55.  
  56. What would ftp have to do with it? There appears to be a misconception of 
  57. the Point `N Click interface folks that an ftp of a file goes direct from 
  58. the remote system to the user's personal computer. Nothing could be further 
  59. from the truth. The file is transferred from the remote site to the local 
  60. ISP and then transfeered from there to the user's computer.
  61.  
  62.  
  63. Same thing with the pretty pictures; they are transferred from the remote 
  64. site to the local ISP then to the user whose computer extracts and 
  65. displays them.
  66.  
  67. T'ain't no magic here, folks... just buffers, fast processors, T-1 links, 
  68. and software that hides the mechanics from the user.
  69.  
  70.